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Description 
TECHNICAL FIELD 

[0001 ] This invention relates generally to computer ac- 
cess control, and more particularly to methods and sys- 
tems for controlling the scope of delegation of authenti- 
cation credentials. 

BACKGROUND 

[0002] Access control is paramount to computer secu- 
rity. To protect the integrity of computer systems and the 
confidentiality of important data, various access control 
schemes have been implemented to prevent unauthor- 
ized users and malicious attackers from gaining access 
to computer resources. 

[0003] To ensure the comprehensiveness of computer 
security, access control is often implemented on various 
levels. For instance, on the level of one computer, a user 
is typically required to go through a logon procedure in 
which the computer determines whether the user is au- 
thorized to use the computer. In addition, on the level of 
a computer network, a user is commonly required to go 
through a user-authentication process for purposes of 
controlling the user's access to various network services. 
Even after a network access control server has authen- 
ticated the user, the user may still have to request a permit 
for a specific server in order to access that service. Var- 
ious schemes based on different protocols, such as the 
Kerberos 5 protocol, have been proposed and imple- 
mented for controlling network access control by means 
of user authentication. 

[0004] Generally, the user logon for a computer and 
the user authentication for network access control are 
two separate procedures. Nevertheless, to minimize the 
burden on a user in dealing with the different access con- 
trol schemes, the user logon and the user authentication 
for network access are sometimes performed together. 
For example, in the case where the user authentication 
is implemented under the Kerberos protocol, when the 
user logs on the computer, the computer may also initiate 
a Kerberos authentication process, in the authentication 
process, the computer contacts a Kerberos Key Distri- 
bution Center (KDC) to first obtain a ticket-granting ticket 
(TGT) for the user. The computer can then use the TOT 
to obtain from the KDC, a session ticket for itself. 
[0005] As networks have evolved, there has been a 
trend to have multiple tiers of server/service computers 
arranged to handle client computer requests. A simple 
example is a client computer making a request to a World 
Wide Web website via the internet. Here, there may be 
a front-end web server that handles the formatting and 
associated business rules of the request, and a back- 
end server that manages a database for the website. For 
additional security, the web site may be configured such 
that an authentication protocol forwards (or delegates) 
credentials, such as, e.g., the user'sTGT, and/or possibly 



other information from the front-end server to a back-end 
server. This practice is becoming increasingly common 
in many websites, and/or other multiple-tiered networks. 
[0006] Thus, any server/computer in possession of the 
5 user's TGT and associated authenticator can request 
tickets on behalf of the user/client from the KDC. This 
capability is currently used to provide forwarded ticket 
delegation. Unfortunately, such delegation to a server is 
essentially unconstrained for the life of the TGT. Conse- 
co quently, there is a need for improved methods and sys- 
tems that support delegation of authentication creden- 
tials in complex network configurations, but in a more 
constrained manner. 

[0007] Furthermore, it is known from "SESAME V2 

^5 Public Key and Authorization Extensions to Kerberos", 
by McMahon P.V., February 16, 1995, public key and 
authorization extensions to Kerberos. In particular, the 
integration of asymmetric key distribution and authoriza- 
tion support to extend Kerberos is described. Moreover, 

20 it is described as a primary extension the support of 
asymmetric inter-realm key distribution to make scalable 
secure interworking practical between the remote 
realms. I n addition , a scheme is defined for securely prop- 
agating principle privileges, including roles and groups, 

25 from clients to servers in order to reduce access control 
management overheads at end-systems, but provide 
policy control safeguards to limit which applications can 
be accessed and which, if any, can act as delegates. 
[0008] Further, it is known from "Interconnecting Do- 

30 mains with Heterogeneous Key Distribution and Authen- 
tication Protocols" by Piessens, F., De Decker, B., and 
Janson, P. mechanisms that can be used in the design 
of a protocol converter for authentication and key distri- 
bution protocols. It is, described that a first mechanism, 

55 based on proxies and a synchronization protocol, allows 
for a transparent protocol conversion. Moreover, it is de- 
scribed that a second mechanism addresses the problem 
of the statefulness of the protocol converter. It these 
mechanisms that, when properly combined, provide for 
a robust, transparent and safe protocol converter for au- 
thentication and key distribution protocols. 
[0009] Therefore, it is the object of the invention to pro- 
vide improved methods and systems for providing con- 
strained delegation of authentication credentials. 

45 [0010] This object is solved by the subject matter of 
the independent claims. 

[0011] Preferred embodiments are the subject of the 
dependent claims. 

[0012] Improved methods and systems are provided 
50 herein, which provide constrained delegation of authen- 
tication credentials. 

[0013] The above stated needs and others are met, 
for example, by a method that includes identifying a target 
service to which access is sought on behalf of a client, 
55 and causing a server to request a new service credential, 
for use by the server, from a trusted third-party. To ac- 
complish this, the server provides the trusted third-party 
with a credential authenticating the server, information 
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about the target service, and a service credential previ- 
ously obtained by the client, or by the server on behalf 
of the client. Here, the new service credential is granted 
in the identity of the client rather than that of the server, 
but can only be used by the server to gain access to the 
target service. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] A more connplete understanding of the various 
nnethods and systems of the present invention may be 
had by reference to the following detailed description 
when taken in conjunction with the accompanying draw- 
ings wherein: 

Fig. 1 is a block diagram generally illustrating an ex- 
emplary computer system on which the present in- 
vention may be implemented. 
Fig. 2 is a block diagram depicting a service-for-user- 
to-proxy (S4U2proxy) process performed within a cli- 
ent-server environment, in accordance with certain 
exemplary implementations of the present invention. 
Fig. 3A is a block diagram depicting a service-for- 
user-to-self (S4U2self) process performed within a 
client-server environment, in accordance with cer- 
tain exemplary implementations of the present in- 
vention. 

Fig. 3B is a block diagram depicting a service-for- 
user-to-self (S4U2self) process performed within a 
client-server environment, in accordance with cer- 
tain further exemplary Implementations of the 
present invention. 

Fig. 4 is an illustrative diagram depicting selected 
portions of a message format suitable for use with 
certain implementations of the present invention. 

DETAILED DESCRIPTION 

[0015] Turning to the drawings, wherein like reference 
numerals refer to like elements, the invention is illustrated 
as being implemented in a suitable computing environ- 
ment. Although not required, the invention will be de- 
scribed in the general context of computer-executable 
instructions, such as program modules, being executed 
by a personal computer. Generally, program modules 
include routines, programs, objects, components, data 
structures, etc. that perform particular tasks or implement 
particular abstract data types. Moreover, those skilled in 
the art will appreciate that the invention may be practiced 
with other computer system configurations, including 
hand-held devices, multi-processor systems, microproc- 
essor based or programmable consumer electronics, 
network PCs, minicomputers, mainframe computers, 
and the like. The invention may also be practiced in dis- 
tributed computing environments where tasks are per- 
formed by remote processing devices that are linked 
through a communications network. In a distributed com- 
puting environment, program modules may be located in 



both local and remote memory storage devices. 
[0016] Fig.1 illustrates an example of a suitable com- 
puting environment 120 on which the subsequently de- 
scribed methods and systems may be implemented. 
5 [0017] Exemplary computing environment 120 is only 
one example of a suitable computing environment and 
is not intended to suggest any limitation as to the scope 
of use or functionality of the improved methods and sys- 
tems described herein. Neither should computing envi- 

10 ronment 120 be interpreted as having any dependency 
or requirement relating to any one or combination of com- 
ponents illustrated in computing environment 120. 
[001 8] The improved methods and systems herein are 
operational with numerous other general purpose orspe- 

15 cial purpose computing system environments or config- 
urations. Examples of well known computing systems, 
environments, and/or configurations that may be suitable 
include, but are not limited to, personal computers, server 
computers, thin clients, thick clients, hand-held or laptop 

20 devices, multiprocessor systems, microprocessor-based 
systems, set top boxes, programmable consumer elec- 
tronics, network PCs, minicomputers, mainframe com- 
puters, distributed computing environments that include 
any of the above systems or devices, and the like. 

25 [0019] As shown in Fig. 1 , computing environment 120 
includes a general-purpose computing device in the form 
of a computer 130. The components of computer 130 
may include one or more processors or processing units 
132, a system memory 134, and a bus 136 that couples 

30 various system components including system memory 
1 34 to processor 1 32. 

[0020] Bus 1 36 represents one or more of any of sev- 
eral types of bus structures, including a memory bus or 
memory controller, a peripheral bus, an accelerated 

35 graphics port, and a processor or local bus using any of 
a variety of bus architectures. By way of example, and 
not limitation, such architectures include Industry Stand- 
ard Architecture (ISA) bus, Micro Channel Architecture 
(MCA) bus, Enhanced ISA (EISA) bus. Video Electronics 

^0 Standards Association (VESA) local bus, and Peripheral 
Component Interconnects (PCI) bus also known as Mez- 
zanine bus. 

[0021] Computer 130 typically includes a variety of 
computer readable media. Such media may be any avail- 
-^5 able media that is accessible by computer 130, and it 
includes both volatile and non-volatile media, removable 
and non-removable media. 

[0022] In Fig. 1 , system memory 1 34 includes compu- 
ter readable media in the form of volatile memory, such 

50 as random access memory (RAM) 140, and/or non-vol- 
atile memory, such as read only memory (ROM) 138. A 
basic input/output system (BIOS) 142, containing the ba- 
sic routines that help to transfer information between el- 
ements within computer 130, such as during start-up, is 

55 stored in ROM 138. RAM 140 typically contains data 
and/or program modules that are immediately accessible 
to and/or presently being operated on by processor 132. 
[0023] Computer 1 30 may further include other remov- 
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able/non-removable, voiatile/non-volatile computer stor- 
age media. For example, Fig. 1 illustrates a hard disk 
drive 144 for reading from and writing to a non-remova- 
ble, non-volatile magnetic media (not shown and typically 
called a "hard drive"), a magnetic disk drive 1 46 for read- 5 
ing from and writing to a removable, non-volatile mag- 
netic disk 148 (e.g., a "floppy disk"), and an optical disk 
drive 1 50 for reading from or writing to a removable, non- 
volatile optical disk 152 such as a CD-ROM, CD-R, CD- 
RW, DVD-ROM, DVD-RAM or other optical media. Hard io 
disk drive 144, magnetic disk drive 146 and optical disk 
drive 1 50 are each connected to bus 1 36 by one or more 
interfaces 154. 

[0024] The drives and associated computer- readable 
media provide nonvolatile storage of computer readable 15 
instructions, data structures, program modules, and oth- 
er data for computer 130. Although the exemplary envi- 
ronment described herein employs a hard disk, a remov- 
able magnetic disk 1 48 and a removable optical disk 1 52, 
it should be appreciated by those skilled in the art that 20 
other types of computer readable media which can store 
data that is accessible by a computer, such as magnetic 
cassettes, flash memory cards, digital video disks, ran- 
dom access memories (RAMs). read only memories 
(ROM), and the like, may also be used in the exemplary 25 
operating environment. 

[0025] A number of program modules may be stored 
on the hard disk, magnetic disk 148, optical disk 152, 
ROM 138, or RAM 140, including, e.g., an operating sys- 
tem 1 58, one or more application programs 1 60, other 30 
program modules 162, and program data 164. 
[0026] The improved methods and systems described 
herein may be implemented within operating system 1 58, 
one or more application programs 160, other program 
modules 1 62, and/or program data 1 64. 35 
[0027] A user may provide commands and information 
into computer 130 through input devices such as key- 
board 166 and pointing device 168 (such as a "mouse"). 
Other input devices (not shown) may include a micro- 
phone, joystick, game pad, satellite dish, serial port, 40 
scanner, camera, etc. These and other input devices are 
connected to the processing unit 1 32 through a user input 
interface 1 70 that is coupled to bus 1 36, but may be con- 
nected by other interface and bus structures, such as a 
parallel port, game port, or a universal serial bus (USB). 45 
[0028] A monitor 1 72 or other type of display device is 
also connected to bus 136 via an interface, such as a 
video adapter 174. In addition to monitor 172, personal 
computers typically include other peripheral output de- 
vices (not shown), such as speakers and printers, which 50 
may be connected through output peripheral interface 
175. 

[0029] Computer 130 may operate in a networked en- 
vironment using logical connections to one or more re- 
mote computers, such as a remote computer 182. Re- 55 
mote computer 182 may include many or all of the ele- 
ments and features described herein relative to computer 
130. 



[0030] Logical connections shown in Fig, 1 are a local 
area network (LAN) 1 77 and a general wide area network 
(WAN) 179. Such networking environments are com- 
monplace in offices, enterprise-wide computer networks, 
intranets, and the Internet. 

[0031] When used in a LAN networking environment, 
computer 130 is connected to LAN 177 via network in- 
terface or adapter 1 86. When used in a WAN networking 
environment, the computer typically includes a modem 
1 78 or other means for establishing communications over 
WAN 1 79. Modem 1 78, which may be internal or external, 
may be connected to system bus 136 via the user input 
interface 170 or other appropriate mechanism. 
[0032] Depicted in Fig. 1 , is a specific implementation 
of a WAN via the Internet. Here, computer 130 employs 
modem 178 to establish communications with at least 
one remote computer 182 via the Internet 180. 
[0033] In a networked environment, program modules 
depicted relative to computer 130, or portions thereof, 
may be stored in a remote memory storage device. Thus, 
e.g., as depicted in Fig. 1, remote application programs 
1 89 may reside on a memory device of remote computer 
182. It will be appreciated that the network connections 
shown and described are exemplary and other means of 
establishing a communications link between the comput- 
ers may be used. 

[0034] This description will now focus on certain as- 
pects of the present invention for controlling the scope 
of delegation of authentication credentials in a client- 
server network environment. While the following descrip- 
tion focuses on exemplary Kerberos-based systems and 
improvements there to, the various methods and systems 
of the present invention are also clearly applicable to oth- 
er authentication systems and techniques. For example, 
certificate-based authentication systems and techniques 
may adapt certain aspects of the present invention. 
[0035] As mentioned above, having possession of a 
client's ticket granting ticket (TGT) and associated au- 
thenticator allows the holder to request tickets on behalf 
of the client from the trusted third-party, e.g., a key dis- 
tribution center (KDC). Such unconstrained delegation 
is currently supported in certain implementations of Ker- 
beros that have forwarded ticket delegation schemes. 
[0036] With this in mind, methods and systems are pro- 
vided to constrain or otherwise better control the delega- 
tion process. The methods and systems can be used with 
different authentication protocols. The delegation proc- 
ess is controlled in certain exemplary implementations 
through a service-for-user-to- proxy (S4U2proxy) tech- 
nique. The S4U2proxy technique is preferably imple- 
mented as a protocol that allows a server or service, such 
as, e.g., a front-end server/service, to request service 
tickets on behalf of a client for use with other servers/ 
services. As described in greater detail below, the 
S4U2proxy protocol advantageously provides for con- 
strained delegation in a controllable manner that does 
not require the client to fonA/ard a TGT to the front-end 
server. 
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[0037] Another technique provided herein is a service- 
for-user-to-self (S4U2self) technique. The S4U2self 
technique or protocol allows a server to request a service 
ticket to itself, but with the client's identity being provided 
in the resulting service ticket. This allows, for example, 
a client, which has been authenticated by other authen- 
tication protocols, to essentially have a service ticket that 
can then be used with the S4U2proxy protocol to provide 
constrained delegation. There are two exemplary forms 
to the S4U2self technique, namely a "no evidence" form 
and an "evidence" form. In the no evidence form, the 
server is trusted to authenticate the client, for example, 
using another security/authentication mechanism that is 
private to the server, for example. In the evidence form, 
the KDC (or a trusted-third-party) makes the authentica- 
tion based on information (evidence) provided about the 
client obtained when the client authenticated to the serv- 
er. 

[0038] With the methods and systems provided herein, 
a client may access servers/services within a Kerberos 
environment regardless as to whether the client has been 
authenticated by Kerberos or some other authentication 
protocol. Consequently, back-end and/or other servers/ 
services can be operated in an essentially Kerberos only 
environment. 

[0039] Reference is now made to the block diagram in 
Fig. 2, which depicts an S4U2proxy protocol/process 
within a client-server environment 200, in accordance 
with certain exemplary implementations of the present 
invention. 

[0040] As shown, a client 202 is operativefy coupled 
to a trusted third-party 204 having operatively configured 
therein an authentication service 206, e.g., a KDC, a cer- 
tificate granting authority, a domain controller, and the 
like. Authentication service 206 is configured to access 
information maintained in a database 208. Client 202 and 
trusted third-party 204 are further operatively coupled to 
a server, namely server A 21 0. Note, as used herein, the 
terms server and service are used intermixable to repre- 
sent the same or similar functionality. 
[0041 ] I n this example, server A 2 1 0 is a front-end serv- 
er to a plurality of other servers. Thus, as depicted, server 
A 210 is operatively coupled to server B 212 and server 
C 214. As illustrated, server B 212 may be a replicated 
service. Also, server C 21 4 is further operatively coupled 
to a server D 216. 

[0042] In response to a user logging on at client 202, 
an authentication request (AS_REQ) message 220 is 
sent to authentication service 206, which responds with 
an authentication reply (AS_REP) message 222. Within 
AS_REP message 222, is a TGT associated with the 
user/client. The same or similar procedure (not illustrat- 
ed) is followed to authenticate server A 210. 
[0043] When client 202 wants to access server A 21 0, 
the client sends a ticket granting service request (TGS_ 
REQ) message 224 to authentication service 206, which 
returns a ticket granting service reply (TGS„REP) mes- 
sage 226. TGS_REP message 226 includes a service 



ticket associated with client 202 and server A 210. Sub- 
sequently, to initiate a communication session, client 202 
forwards the service ticket to server A 210, in an appli- 
cation protocol request (AP_REQ) message 228. Such 
5 processes/procedures are well known, and as such are 
not disclosed herein in greater detail. 
[0044] In the past, to support delegation, the client 
would need to provide server A 21 0 with the client's TGT 
to allow server A 21 0 to request additional service tickets 

^0 on behalf of client 202. This is no longer necessary. In- 
stead, when server A 21 0 needs to access another server 
on behalf of client 202, for example, server C 214, then 
server A 21 0 and authentication service 206 operate ac- 
cording to the S4U2proxy protocol. 

^5 [0045] Thus, by way of example, in accordance with 
certain exemplary S4U2proxy protocol implementations; 
server A 210 sends a TGS_REQ message 230 to au- 
thentication service 206. TGS_REQ message 230 in- 
cludes the TGT for server A 210 and the service ticket 

20 received from client 202, and identifies the desired or 
targeted server/service to which client 202 is seeking ac- 
cess, e.g., server C 214. In Kerberos, for example, there 
is a defined extensible data field, which is typically re- 
ferred to as the "additional tickets" field. This additional 

25 tickets field can be used in the S4U2proxy protocol to 
carry the service ticket received from client 202, and a 
KDC options field can include a flag or other indicator 
that instructs the receiving KDC to look in the additional 
tickets field for a ticket to be used to supply a client iden- 

30 tity. Those skilled in the art will recognize that these or 
other fields and/or data structures can be used to carry 
the necessary information to authentication service 206. 
[0046] In processing TGS_REQ 230, authentication 
service 206 determines if client 202 has authorized del- 

35 egation, for example, based on the value of a "forward- 
able flag" established by client 202. Thus, delegation per 
client is enforced by the presence of the forwardable flag 
in the client's service ticket. If client 202 does not want 
to participate in delegation, then the ticket is not flagged 

40 as f onwardable. Authentication service 206 will honor this 
flag as a client initiated restriction. 
[0047] In other implementations, authentication serv- 
ice 206 may access additional information in database 
208 that defines selected services that server A 210 is 

45 allowed to delegate to (or not delegate to) with respect 
to client 202. 

[0048] If authentication service 206 determines that 
server A 2 1 0 is allowed to delegate to the targeted server/ 
service, then a TGS„REP message 232 is sent to server 
50 A 21 0. TGS_REP message 232 includes a service ticket 
for the targeted server/service. This service ticket ap- 
pears as if client 202 requested it directly from authenti- 
cation service 206, for example, using the client's TGT. 
However, this was not done. Instead, authentication serv- 
es ice 206 accessed the similar/necessary client information 
in database 208 after being satisfied that the authenti- 
cated client is essentially involved in the request based 
on the service ticket that authenticated server A 21 0 re- 



5 



9 



EP1 619 856 B1 



10 



ceived from client 202 and included in TGS_REQ mes- 
sage 230. However, since the client information is carried 
in the client's ticket, the server only needs to copy the 
data from the ticket. Thus, database 208 can be used, 
but copying the data in the ticket tends to be more effi- 
cient. 

[0049] In certain implementations, for example, TGS 
REP message 232 identifies the targeted server/service 
and client 202, and further includes implementation-spe- 
cific identity/user/client account data, e.g., in the form of 
a privilege attribute certificate (PAC), a security identifier, 
a Unix ID, Passport ID, a certificate, etc.. A PAC, for ex- 
ample, may be generated by authentication service 206, 
or simply copied from the client's service ticket that was 
included in TGS__REQ message 230. 
[0050] PAC or other user/client account data may also 
be configured to include information relating to the scope 
of delegation. Thus, for example, attention is drawn to 
Fig. 4, which is an illustrative diagram depicting selected 
portions of a Kerberos message 400 having a header 
402 and a PAC 404. Here, PAC 404 includes delegation 
information 406. As illustrated, delegation information 
406 includes compound identity information 408 and ac- 
cess restriction information 410. 

[0051 ] Compound identity information 408 may, for ex- 
ample, include recorded information about the delegation 
process, such as, e.g., an indication regarding the fact 
that server A 21 0 requested the service ticket on behalf 
of user/client 202. Here, a plurality of such recorded in- 
formation may be provided that can be used to string 
together or otherwise identify the history over multiple 
delegation processes. Such information may be useful 
for auditing purposes and/or access control purposes. 
[0052] Access restriction information 410 may be 
used, for example, in conjunction with an access control 
mechanism to selectively allow access to certain servers/ 
services provided that client 202 has either directly or 
indirectly through server A 21 0 sought to access the ser- 
er/service, but not if the server/service is being indirectly 
sought through server B 21 2. This feature adds additional 
control over the delegation of authentication credentials. 
[0053] In the above examples client 202 was authen- 
ticated by authentication service 206. However, it is rec- 
ognized that other clients may not be so authenticated. 
An example of such a situation Is depicted in Fig. 3A. 
Here, a client 302 has been authenticated using a differ- 
ent authentication protocol mechanism 303. For exam- 
pie, authentication protocol mechanism 303 may include 
Passport, secure sockets layer (SSL), NTLM, Digest, or 
other like authenticating protocols/procedures. Here, in 
this example. It is assumed that client 302 chooses to 
access a targeted service, which just so happens to be 
provided by server C 214. This choice can be satisfied 
using the above-described S4U2proxy protocol, but only 
after server A 210 has completed/followed an S4U2self 
protocol/procedure. 

[0054] One basic premise with the S4U2self protocol 
is that the server, e.g., server A 210, is able to request a 



service ticket to itself for any user/client that is accessing 
the server and which the server has itself authenticated. 
The exemplary S4U2self protocol described herein is 
configured to support clients that have authenticating 
5 "evidence" and clients that do not have such authenti- 
cating evidence. 

[0055] In the absence of authentication evidence that 
can be evaluated by authentication service 206, server 
A 210 will need to come to "trust" client 302. Thus, for 

^0 example, if client 302 has an authentication certificate or 
like mechanism 304 that server A 21 0 is able to validate, 
then the client 302 may be determined to be "trusted". 
Here, client 302 is essentially being authenticated by 
server A 210. Next, server A 210 sends a TGS„REQ 

^5 message 306 to authentication service 206 requesting a 
service ticket to itself for client 302. In response, authen- 
tication service 206 generates a TGS_REP message 308 
that includes the requested service ticket. The received 
service ticket is then used in a subsequent S4U2proxy 

^0 protocol/procedure to request a service ticket to server 
C 21 4 for client 302. In certain Kerberos implementations, 
for example, this requires that a fonwardable flag in the 
TGS_REP message 308 be set to allow fonwarding of 
the service ticket. The trusted third-party may also build 

25 a PAC for client 302, which can then be included in the 
resulting service ticket 

[0056] If evidence of the authentication does exist for 
a client 302', then server A 2 1 0 can include such evidence 
in a TGS_REQ message 312 as additional pre-authen- 

30 tication data. This Is Illustratively depicted in environment 
300' in Fig. 3B. Here, evidence information 310 is pro- 
vided by client 302' to server A 21 0. Evidence Information 
310 may include, for example, a challenge/response di- 
alog, or other, information generated by another "trusted" 

35 entity. Upon receipt of evidence information 31 0 and sub- 
sequent validation, authentication service 206 will grant 
the requested service ticket to server A 210 itself. It is 
noted, that in certain Implementations, with the use of 
evidence it may be possible for the server to obtain a 

^0 restricted TGT for the client. 

[0057] In certain Kerberos implementations, the for- 
wardable flag in the TGS_REP message 314 will be set 
to allow fonwarding of the service ticket. If a PAC was 
provided in TGS__REQ message 31 2, then it can be used 

^5 in the service ticket, otherwise, a PAC may be generated 
by authentication service 206 (here, a KDC) basted an 
evidence Information 31 0. For example, in S4U2self , the 
identity of the client is included in the pte-anthentlcation 
data. This identity can be used in the construction of the 

50 PAC for that client and added to the issued service ticket 
to the server (for the client). 

[0058] Although some preferred implementations of 
the various methods and systems of the present inven- 
tion have been Illustrated in the accompanying Drawings 
55 and described in the foregoing Detailed Description, It 
will be understood that the invention is not limited to the 
exemplary embodiments disclosed, but is capable of nu- 
merous rearrangements, modifications and substitutions 
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without departing from the scope of the invention. 
[0059] The following is a list of further preferred 
embodiments of the invention: 

Embodiment 1. A method comprising: 5 

Identifying a target service to which access is 
sought on behalf of a client; 
causing a server operati vely coupled to the client 
to request access to the target service on behalf io 
of the client, from a trusted third-party, wherein 
the server provides the trusted third-party with 
a credential authenticating the server, informa- 
tion about the target service, and a service cre- 
dential previously provided by the client to the 15 
server. 

Embodiment 2. The method as recited in embodi- 
ment 1 , wherein the trusted third-party includes at 
least one service selected from a group of services 20 
comprising a key distribution center (KDC) service, 
a certificate granting authority service, and a domain 
controller service. 

Embodiment 3. The method as recited in embodi- 25 
ment 2, wherein the trusted third-party provides the 
server with a new service credential granted in the 
name of the client rather than the server. 

Embodiment 4. The method as recited in embodi- 30 
ment 3, wherein the new service credential is con- 
figured for use by the server and the target service 
to which access is sought. 

Embodiment 5. The method as recited in embodi- 35 
ment 3, wherein the credential authenticating the 
server is a ticket that includes a ticket granting ticket 
associated with the server. 

Embodiment 6. The method as recited in embodi- ^0 
ment 1 , further comprising: causing the trusted third- 
party to verify that the client has authorized delega- 
tion. 

Embodiment 7. The method as recited in embodi- 45 
ment 6, wherein: the trusted third-party includes a 
key distribution center (KDC); and 
causing the trusted third-party to venfy that the client 
has authorized delegation includes verifying the sta- 
tus of a restriction placed on the ticket originating so 
from the client. 

Embodiment 8. The method as recited in embodi- 
ment 1 , further comprising: 

55 

causing the trusted-third-party to selectively de- 
termine if the client is allowed to participate in 
delegation either based on information selected 



from a group comprising an identity of the client, 
a group affiliation associated with the client. 

Embodiment 9. The method as recited in embodi- 
ment 1 , wherein the server is a front-end server with 
respect to a back-end server that is coupled to the 
front-end server, and wherein the back-end server 
is configured to provide the target service to which 
access is sought. 

Embodiment 10. The method as recited in embodi- 
ment 1 , wherein: 

the trusted third-party includes a key distribution 
center (KDC); 

the KDC provides a ticket-granting-ticket asso- 
ciated with the client to the client; and 
the client does not provide the ticket granting 
ticket to the server. 

Embodiment 1 1 . The method as recited in embodi- 
ment 1 , wherein: 

the trusted third-party includes a key distribution 
center (KDC); and 

the server requests the new credential in a ticket 
granting service request message that includes 
a service ticket provided by the client to the serv- 
er. 

Embodiment 12. A method comprising: 

identifying a target service to which access is 
sought on behalf of a client; and 
causing a server operatively coupled to the client 
to request access to the target service on behalf 
of the client, from a trusted third party, wherein 
the server provides the trusted third party with 
a service credential authenticating the server, 
information about the target service, and a serv- 
ice credential previously provided by the client 
for the service, and wherein the client ticket in- 
cludes implementation-specific identity informa- 
tion. 

Embodiment 13. The method as recited in embodi- 
ment 12, wherein the implementation-specific iden- 
tity information includes information selected from a 
group comprising privilege attnbute certificate (PAC) 
information, security identifier information, Unix 
identifier information, Passport identifier information, 
certificate information. 

Embodiment 14. The method as recited in embodi- 
ment 1 3, wherein the PAC information includes com- 
pound identity information. 

Embodiment 15. The method as recited in embodi- 
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ment 13, wherein the PAC information includes ac- 
cess control restrictions for use as delegation con- 
straints. 

Embodiment 1 6. A computer- readable medium hav- 5 
ing computer-executable instructions for performing 
tasks comprising: 

in a server, determining a target service to which 
access is sought on behalf of a client coupled io 
to the server; 

requesting a new service credential from a trust- 
ed third-party by providing the trusted third-party 
with a credential authenticating the server, in- 
formation about the target service, and a service 15 
credential associated with the client and the re- 
questing server. 

Embodiment 1 7. The computer-readable medium as 
recited in embodiment 1 6, wherein the trusted third- 20 
party includes at least one service selected from a 
group of services comprising a key distribution cent- 
er (KDC) service, a certificate granting authority 
service, and a domain controller service. 

25 

Embodiment 1 8. The computer-readable medium as 
recited in embodiment 17, wherein the new service 
credential is granted in the name of the client rather 
than the server. 

30 

Embodiment 1 9. The computer- readable medium as 
recited in embodiment 18, wherein the service cre- 
dential Is configured for use by the server and the 
target service. 

35 

Embodiment 20. The computer-readable medium as 
recited in embodiment 1 8, wherein the credential au- 
thenticating the server includes a ticket granting tick- 
et associated with the server. 

40 

Embodiment 21 . The computer-readable medium as 
recited in embodiment 16, further comprising: 

causing the trusted third-party to verify that the 
client has authorized delegation. 45 

Embodiment 22. The computer-readable medium as 
recited in embodiment 21, wherein: 

the trusted third-party includes a key distribution 50 
center (KDC); and 

causing the trusted third-party to verify that the 
client has authorized delegation includes verify- 
ing the status of a forwardable flag value as set 
by the client. 55 

Embodiment 23. The computer-readable medium as 
recited in embodiment 16, wherein the server is a 



front-end server with respect to a back-end server 
coupled to the front-end server, and wherein the 
back-end server is configured to provide the target 
service. 

Embodiment 24. The computer-readable medium as 
recited in embodiment 16, wherein: 

the trusted third-party includes a key distribution 
center (KDC); 

the KDC provides a ticket-granting-ticket asso- 
ciated with the client to the client; and 
the client does not provide the ticket granting 
ticket to the server. 

Embodiment 25. The computer-readable medium as 
recited in embodiment 16, wherein: 

the trusted third-party includes a key distribution 
center (KDC); and 

the requesting server requests the new service 
credential in a ticket granting service request 
message that includes a service ticket provided 
by the client to the server. 

Embodiment 26. A system comprising: 

a credential granting mechanism configured to 
receive a request for a new service credential 
from a server and in response generate the new 
service credential if delegation is allowable, and 
wherein the request includes: 

a credential authenticating the requesting 
server, identifying information about a tar- 
get service to which access is sought on 
behalf of a client coupled to the server, and 
a service credential that was previously 
granted to the client for use with the server. 

Embodiment 27. The system as recited in embodi- 
ment 26, wherein the credential granting mechanism 
is provided by a trusted third party and includes at 
least one service selected from a group of services 
comprising a key distribution center (KDC) service, 
a certificate granting authority service, and a domain 
controller service. 

Embodiment 28. The system as recited in embodi- 
ment 27, wherein the new service credential is grant- 
ed in the name of the client rather than the server. 

Embodiment 29. The system as recited in embodi- 
ment 28, wherein the service credential is configured 
for use by the server and the target service. 

Embodiment 30. The system as recited in embodi- 
ment 28, wherein the credential authenticating the 
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server includes a ticket granting ticket associated 
with the server, and which was previously granted 
by the credential granting mechanism. 

Embodiment 31 . A system comprising; 5 

a server configured to generate a request for a 
new service credential from a trusted third-party, 
the new service credential being associated with 
a client and a target service, the request com- io 
prising: 

a credential authenticating the server, infor- 
mation about the target service, and a serv- 
ice credential associated with the client and ^5 
the server. 



providing the client with a client ticket granting 
ticket and a service ticket for use with the server; 
providing the server with a new service ticket for 
use by the server for use with a new service 
without requiring the server to have access to 
the client ticket granting ticket. 

Embodiment 39. The method as recited in embodi- 
ment 38, further comprising: 

causing the server to request the new service 
ticket on behalf of the client by forwarding the 
server ticket granting ticket, information identi- 
fying the new service, and the service ticket to 
a trusted third party. 



Embodiment 32. The system as recited in embodi- 
ment 31 , wherein the trusted third-party includes at 
least one service selected from a group of services 20 
comprising a key distribution center (KDC) service, 
a certificate granting authority service, and a. domain 
controller service. 

Embodiment 33. The system as recited in embodi- ^5 
ment 31 , wherein the credential authenticating the 
server includes a ticket granting ticket associated 
with the server. 

Embodiment 34. The system as recited in embodi- 3o 
ment 31 , wherein the server is a front-end server 
with respect to the service. 

Embodiment 35. The system as recited in embodi- 
ment 31 , wherein the server requests the new serv- 35 
ice credential in a ticket granting service request 
message that includes the service ticket associated 
with the client and the server. 

Embodiment 36. A computer-readable medium hav- 
ing stored thereon a data structure, comprising: 

a credential authenticating a first server, 
information identifying a second server, and 
a service credential associated with a client and ^5 
the first server. 

Embodiment 37. The computer-readable medium as 
recited in embodiment 36, wherein the credential au- 
thenticating the first server includes a ticket-grant- so 
ing-ticket (TGT) and the service credential includes 
a service ticket. 

Embodiment 38. A method comprising: 

55 

separately authenticating a server and a client; 
providing the server with a server ticket granting 
ticket; 



Claims 

1 . A method for constraining a scope of delegation by 
a client to a server, comprising: 

identifying a target service (Server B-D) to which 
access is sought on behalf of a client (202) that 
has been authenticated using a first authentica- 
tion method (303); 

causing a server (210) that is operatively cou- 
pled to the target service and the client to request 
a service credential (303) to itself from a second 
authentication method based trusted third-party 
(204) by identifying the client and the first au- 
thentication method; and 
causing the server to request from the second 
authentication method trusted third-party, a new 
service credential (308) to itself for the client, for 
use by the server and the target service, from 
the second authentication method based trusted 
third-party, 

wherein the server provides the trusted third-party 
with a credential (306) authenticating the server to 
access the target service within a scope constrained 
by the client, information about the target service, 
and the service credential to itself. 

2. The method as recited in claim 1 , wherein the second 
authentication method based trusted third-party 
(204) includes at least one service (206) selected 
from a group of services comprising a key distribution 
center (KDC) service, a certificate granting authority 
service, and a domain controller service. 

3. The method as recited in claim 2, wherein the new 
service credential (308) is granted in an identity of 
the client (202) rather than an identity of the server 
(210). 

4. The method as recited in claim 3, wherein the new 
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service credential (308) is configured for use by the 
server (210) and the target service (Server B-D) to 
which access is sought. 

5. The method as recited in claim 3, wherein the ere- 5 
dentiai (306) authenticating the server (21 0) includes 

a ticket granting ticket associated with the server. 

6. The method as recited in claim 1 , further comprising: 

10 

upon receiving a request (306) for the new serv- 
ice credential (308) from the server (21 0), caus- 
ing the second authentication method based 
trusted third-party (204) to verify that the client 
(202) has authorized delegation. 15 

7. The method as recited in claim 1 , wherein the server 
(210) is a front-end server with respect to a back- 
end server that is coupled to the front-end server, 
and wherein the back-end server is configured to 20 
provide the target service. 



10, wherein the second authentication method 
based trusted third-party (204) includes a key distri- 
bution center (KDC). 

12. The computer-readable medium as recited in claim 

11, wherein the new service credential (308) in- 
cludes a service credential granted in an identity of 
the client rather than an identity of the server. 

13. The computer- readable medium as recited in claim 

12, wherein the new service credential is configured 
for use by the server (210) and the target service 
(Server B-D). 

14. The computer-readable medium as recited in claim 
12, wherein the credential (306) authenticating the 
server (210) includes a ticket granting ticket associ- 
ated with the server. 

15. The computer-readable medium as recited in claim 
10, further comprising: 



8. The method as recited in claim 1, wherein the first 
authentication method (303) is selected from a group 
of authentication methods comprising Passport, 
SSL, NTLM, and Digest. 

9. The method as recited in claim 1 , wherein the second 
authentication method (206) includes a Kerberos au- 
thentication protocol. 

10. A computer-readable medium having computer-ex- 
ecutable instructions for performing tasks compns- 
ing: 

identifying a target service (Server B-D) to which 
access is sought on behalf of a client (202) that 
has been authenticated using a first authentica- 
tion method (303); 

causing a server (210) that is operatively cou- 
pled to the target service and the client to request 
a service credential (308) to itself from a second 
authenticatiorr method based trusted third-party 
(204) by identifying the client and the first au- 
thentication protocol; and 
causing the server to request from the second 
authentication method trusted third-party, a new 
service credential (308) to itself for the client, for 
use by the server and the target service, from 
the second authentication method based trusted 
third-party, wherein the server provides the 
trusted third-party with a credential (306) au- 
thenticating the server to access the target serv- 
ice within a scope constrained by the client, in- 
formation about the target service, and the serv- 
ice credential to itself. 

11. The computer-readable medium as recited in claim 



upon receiving a request for the new service cre- 
dential (308) from the server (210), causing the 
2^ second authentication method based trusted 

third-party (204) to verify that the client(202) has 
authonzed delegation. 

16. The computer-readable medium as recited in claim 
30 10, wherein the server (210) is a front-end server 

with respect to a back-end server that is coupled to 
the front-end server, and wherein the back-end serv- 
er is configured to provide the target service (Server 
B-D). 

35 

17. The computer-readable medium as recited in claim 
10, wherein the first authentication method (303) is 
selected from a group of authentication methods 
comprising Passport, SSL, NTLM, and Digest. 

40 

18. The computer-readable medium as recited in claim 
1 0, wherein the second authentication method (206) 
includes a Kerberos authentication protocol. 



45 19. A server system comprising: 

means configured to identify a target service 
(Server B-D) to which access is sought on behalf 
of a client (202) that has been authenticated us- 

^0 ing a first authentication method (303), 

means configured to request a service creden- 
tial (308) to itself from a second authentication 
method based trusted third-party (204) by iden- 
tifying the client and the first authentication 

55 method, and 

means configured to subsequently request a 
new service credential to itself for the client, for 
use by the server system and the target service, 
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from the second authentication nnethod based 
trusted third-party, 

wherein the server system further comprises 
means configured to provide the second authen- 
tication methodtrustedthird-party with a creden- 
tial (306) authenticating the server to access the 
target service within a scope constrained by the 
client, information about the target service, and 
the service credential to itself. 

20. The system as recited in claim 19, further comprising 
means configured to grant the new service credential 
(308) in an identity of the client(202) rather than the 
server system (210). 

21 . The system as recited in claim 20, wherein the new 
service credential (308) is configured for use by the 
server system (210) and the target service (Server 
B-D). 

22. The system as recited in claim 20, wherein the cre- 
dential (306) authenticating the server system (210) 
includes a ticket granting ticket associated with the 
server. 

23. The system as recited in claim 1 9, wherein the server 
system (21 0) is a front-end server with respect to a 
back-end server that is coupled to the front-end serv- 
er, and wherein the back-end server is configured to 
provide the target service (Server B-D). 

24. The system as recited in claim 19, wherein the first 
authentication method (303) is one of a group of au- 
thentication methods comprising Passport, SSL, 
NTLM, and Digest. 

25. The system as recited in claim 1 9, wherein the sec- 
ond authentication method (206) comprises means 
configured to use a Kerberos authentication proto- 
col. 
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Patentanspruche 



rungsverfahrens anfordert, indem er den Client 
und das erste Authentfizierungsverfahren iden- 
tifiziert; und 

Veranlassen, dass der Server von der vertrau- 
enswurdigen dritten Seite auf Basis des zweiten 
Authentifizierungsverfahrens ein neues Dienst- 
Credential (308) an sich selbst fur den Client zur 
Verwendung durch den Server und den Ziel- 
Dienst von der vertrauenswurdigen dritten Seite 
auf Basis des zweiten Authentifizierungsverfah- 
rens anfordert, wobei der Server der vertrauens- 
wurdigen dritten Seite ein Credential (306) be- 
reltstellt, das den Server zum Zugreifen auf den 
Ziel-Dienst innerhalb eines Bereichs authentifi- 
ziert, der durch den Client, Informationen uber 
den Ziel-Dienst und das Dienst-Credentiat an 
sich selbst eingeschrankt wird. 

Verfahren nach Anspruch 1, wobei die vertrauens- 
wurdige dritte Seite (204) auf Basis des zweiten Au- 
thentifizierungsverfahrens wenigstens einen Dienst 
(206) enthalt, der aus einer Gruppe von Diensten 
ausgewahit wird, die einen Dienst eines Schlussel- 
Verteilungszentrums (KDC), einen Dienst einer Zer- 
tifikatsverteilungsbehorde und einen Dienst eines 
Domain-Controllers umfasst. 

Verfahren nach Anspruch 2, wobei das neue Dienst- 
Credential (308) in einer Identitat des Client (202) 
anstelle einer Identitat des Servers (21 0) erteilt wird. 

Verfahren nach Anspruch 3, wobei das neue Dienst- 
Credential (308) zur Verwendung durch den Server 
(210) und den Ziel-Dienst (Server B-D), auf den Zu- 
griff angefordert wird, konfiguriert ist. 

Verfahren nach Anspruch 3, wobei das Credential 
(306), das den Server (21 0) authentifiziert, ein Ticket 
zur Ticketausstellung (ticket granting ticket) enthalt, 
das mit dem Server zusammenhangt. 

Verfahren nach Anspruch 1, das des Weiteren um- 
fasst: 



1. Verfahren zum Einschranken eines Bereichs von 45 
Delegation durch einen Client an einen Server, das 
umfasst 

Identifizieren eines Ziel-Dienstes (Server B-D), 
zu dem Zugang im Namen eines Client (202) 50 
angefordert wird, der unter Verwendung eines 
ersten Authentifizierungsverfahrens (303) au- 
thentifiziert worden ist; 

Veranlassen, dass ein Server (210), der funk- 
tionell mit dem Ziel-Dienst und dem Client ge- 55 
koppelt ist, ein Dienst-Credential (303) an sich 
selbst von einer vertrauenswurdigen dritten Sei- 
te (204) auf Basis eines zweiten Authentifizie- 



beim Empfangen einer Anforderung (306) des 
neuen Dienst-Credentials (308) von dem Server 
(210) Veranlassen, dass die vertrauenswurdige 
dritte Seite (204) auf Basis des zweiten Authen- 
tifizierungsverfahrens verifiziert, dass der Client 
(202) uber autorisierte Delegierung verfugt. 

7. Verfahren nach Anspruch 1 , wobei der Server (21 0) 
ein Front-End-Server in Bezug auf einen Back-End- 
Server ist, der mit dem Front-End-Server gekoppelt 
ist, und wobei der Back-End-Server zum Bereitstel- 
len des Ziel-Dienstes konfiguriert ist. 

8. Verfahren nach Anspruch 1 , wobei das erste Authen- 
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tifizierungsverfahren (303) aus einer Gruppe von Au- 
thentifizierungsverfahren ausgewahit wird, die 
Passport, SSL, NTLM und Digest umfasst. 

9. Verfahren nach Anspruch 1, wobei das zweite Au- 5 
thentifizierungsverfahren (206) ein Kerberos-Au- 
thentifizierungsprotokoll enthalt. 

10. Computerlesbares Medium, das durcli Computer 
ausfuhrbare Befelile zum Durchfuhren von Aufga- io 
ben aufweist, die umfassen: 

identifizieren eines Ziel-Dienstes (Server B-D), 
zu dem Zugang im Namen eines Client (202) 
angefordert wird, der unter Verwendung eines 15 
ersten Authentifizierungsverfahrens (303) au- 
thentifiziert worden ist; 

Veranlassen, dass ein Server (210), der funk- 
tionell mit dem Ziel-Dienst und dem Client ge- 
koppelt ist, ein Dienst-Credential (308) an sich 20 
selbst von einer vertrauenswurdigen dritten Sei- 
te (204) auf Basis eines zweiten Authentifizie- 
rungsverfahrens anfordert, indem er den Client 
und das erste Authentifizierungsprotokoll iden- 
tifiziert; und 25 
Veranlassen, dass der Server von der vertrau- 
enswurdigen dritten Seite auf Basis des zweiten 
Authentifizierungsverfahrens ein neues Dienst- 
Credential (308) an sich selbst fur den Client zur 
Verwendung durch den Server und den Ziel- 30 
Dienst von der vertrauenswurdigen dritten Seite 
auf Basis des zweiten Authentifizierungsverfah- 
rens anfordert, wobei der Server der vertrauens- 
wurdigen dritten Seite ein Credential (306) be- 
reitstellt, das den Server zum Zugreifen auf den 35 
Ziel-Dienst innerhalb eines Bereichs authentifi- 
ziert, der durch den Client, Informationen uber 
den Ziel-Dienst und das Dienst-Credential an 
sich selbst eingeschrankt wird. 

40 

1 1 . Computertesbares Medium nach Anspruch 1 0, wo- 
bei die vertrauenswurdige dritte Seite (204) auf Basis 
des zweiten Authentifizierungsverfahrens ein 
Schlussel-Verteilungszentrum (KDC) enthalt. 

45 

12. Computerlesbares Medium nach Anspruch 11, wo- 
bei das neue Dienst-Credential (308) eine Dienst- 
Credential enthalt, das in einer Identitat des Client 
anstelte einer identitat des Servers erteilt wird. 

50 

13. Computerlesbares Medium nach Anspruch 12, wo- 
bei das neue Dienst-Credential zur Verwendung 
durch den Server (210) und den Ziel-Dienst (Server 
B-D) konfiguriert ist. 

55 

14. Computerlesbares Medium nach Anspruch 12, wo- 
bei das Credential (306), das den Server (210) au- 
thentifiziert, ein Ticket zur TIcketaussteliung (ticket 
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granting ticket) enthalt, das mit dem Server zusam- 
menhangt. 

15. Computerlesbares Medium nach Anspruch 10, das 
des Weiteren umfasst: 

beim Empfangen einer Anforderung des neuen 
Dienst-Credential (308) von dem Server (210) 
Veranlassen, dass die vertrauenswurdige dritte 
Seite (204) auf Basis des zweiten Authentifizie- 
rungsverfahrens verifiziert, dass der Client (202) 
uber authorisierte Delegierung verfugt. 

16. Computerlesbares Medium nach Anspruch 10, wo- 
bei der Server (210) ein Front-End-Server in Bezug 
auf einen Back-End-Server ist, der mit dem Front- 
End-Server gekoppelt ist, und wobei der Back-End- 
Server zum Bereitstellen des Ziel-Dienstes (Server 
B-D) konfiguriert ist 

17. Computerlesbares Medium nach Anspruch 10, wo- 
bei das erste Authentifizierungsverfahren (303) aus 
einer Gruppe von Authentifizierungsverfahren aus- 
gewahit wird, die Passport, SSL, NTLM und Digest 
umfasst. 

18. Computerlesbares Medium nach Anspruch 10, wo- 
bei das zweite Authentifizierungsverfahren (206) ein 
Kerberos-Authentfizierungsprotokoll enthalt. 

19. Server-System, das umfasst: 

eine Einrichtung, die zum Identifizieren eines 
Ziel-Dienstes (Server B-D) konfiguriert 
ist, zu dem Zugang im Namen eines Client (202) 
angefordert wird, der unter Verwendung eines 
ersten Authentifizierungsverfahrens (303) au- 
thentifiziert worden ist, 

eine Einrichtung, die zum Anforderung eines 
Dienst-Credentials (308) an sich selbst von ei- 
ner vertrauenswurdigen dritten Seite (204) auf 
Basis eines zweiten Authentifizierungsverfah- 
rens durch Identifizieren des Client und des er- 
sten Authentifizierungsverfahrens konfiguriert 
ist, und 

eine Einrichtung, die zum anschlieBenden An- 
fordern eines neuen Dienst-Credentials an sich 
selbst fur den Client zur Verwendung durch das 
Server-System und den Ziel-Dienst von der ver- 
trauenswurdigen dritten Seite auf Basis des 
zweiten Authentifizierungsverfahrens konfigu- 
riert ist, 

wobei das Server-System des Weiteren eine 
Einrichtung umfasst, die so konfiguriert ist, dass 
sie der vertrauenswurdigen dritten Seite auf Ba- 
sis des zweiten Authentifizierungsverfahrens 
ein Credential (306) bereitstellt, das den Server 
zum Zugreifen auf den Ziel-Dienst innerhalb ei- 
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nes Bereiches authentifiziert, der durch den Cli- 
ent, Informationen uber den Ziel-Dienst und das 
Dienst-Credential an sich selbst eingeschrankt 
wird. 

5 

20. System nach Anspruch 19, das des Weiteren eine 
Einrichtung umfasst, die so konfiguriert ist, dass sie 
das neue Dienst-Credential (308) in einer Identitat 
des Client (202) anstefle des Server-Systems (210) 
erteilt. io 

21 . System nach Anspruch 20, wobei das neue Dienst- 
Credential (308) zur Verwendung durch das Server- 
System (21 0) und den Ziel-Dienst (Server B-D) kon- 
figuriert ist. 15 

22. System nach Anspruch 20, wobei das Credential 
(306), das das Server-System (210) authentifiziert, 
ein Ticket zur Ticketausstellung (ticket granting tik- 
ket) enthalt, das mit dem Server zusammenhangt. 

23. System nach Anspruch 19, wobei das Server-Sy- 
stem (210) ein Front- End-Server in Bezug auf einen 
Back-End-Server ist, der mit dem Front-End-Server 
gekoppelt ist, und wobei der Back-End-Server so ^5 
konfiguriert ist, dass er den Ziel-Dienst (Server B-D) 
bereitstellt. 

24. System nach Anspruch 1 9, wobei das erste Authent- 
fizierungsverfahren (303) eines einer Gruppe von 30 
Authentifizierungsverfahren ist, die Passport, SSL, 
NTLM und Digest umfasst. 

25. System nach Anspruch 19, wobei das zweite Au- 
thentifizierungsverfahren (206) eine Einrichtung um- 35 
fasst, die so konfiguriert ist, dass sie ein Kerberos- 
Authentifizierungsprotokoll verwendet. 



Revendications 40 

1 . Precede pour restreindre une etendue de delegation 
d'un client a un serveur, comprenant les etapes qui 
consistent a: 

45 

identifier un service cible (Serveur B-D) pour le- 
quel un acces est recherche pour le compte d'un 
client (202) qui a ete authentifie a I'aide d'une 
premiere methode d'authentification (303); 
amener un serveur (21 0) relie de maniere ope- 50 
rationnelle au service cible et au client a requerir 
un pouvoir de delegation de service (303) a son 
nom d'un tiers de confiance (204) en vertu d*une 
seconde methode d'authentification en identi- 
fiant le client et la premiere methode d'authen- 55 
tification; et 

amener le serveur a requerir du tiers de confian- 
ce en vertu de la seconde methode d'authenti- 



fication, un nouveau pouvoir de delegation de 
service (308) a son nom pour le client, destine 
a etre utilise par le serveur et le service cible, 
de la part du tiers de confiance en vertu de la 
seconde methode d'authentification, le serveur 
fournissant au tiers de confiance un pouvoir de 
delegation (306) qui authentifie I'acces du ser- 
veur au service cible dans un cadre restreint par 
le client, des informations concernant le service 
cible, et le pouvoir de delegation de service a 
son nom. 

Precede tel que defini dans la revendication 1 , dans 
lequel le tiers de confiance (204) en vertu de la se- 
conde methode d'authentification comprend au 
moins un service (206) choisi dans un groupe de 
services comprenant un service d'un centre de dis- 
tribution de cles (KDC), un service d'une autorite de 
delivrance de certificats et un service d'un organe 
de controle de domaine. 

Precede tel que defini dans la revendication 2, dans 
lequei le nouveau pouvoir de delegation de service 
(308) est defivre au nom du client (202) et non au 
nom du serveur (210). 

Precede tel que defini dans la revendication 3, dans 
lequel le nouveau pouvoir de delegation de service 
(308) est configure pour etre utilise par le serveur 
(210) et le service cible (Serveur B-D) pour lequel 
un acces est recherche. 

Precede tel que defini dans la revendication 3, dans 
lequel le pouvoir de delegation (306) authentifiant le 
serveur (210) comprend un ticket de delivrance de 
ticket assocle au serveur. 

Precede tel que defini dans la revendication 1 , com- 
prenant egalement les etapes qui consistent a: 

a la reception d'une demande (306) requerant 
le nouveau pouvoir de delegation de service 
(308) de la part du serveur (21 0), amener le tiers 
de confiance (204) en vertu de la seconde me- 
thode d'authentification a verifier que le client 
(202) a une delegation autorisee. 

Precede tel que defini dans la revendication 1 , dans 
lequel le serveur (210) est un serveur frontal par rap- 
port a un serveur dorsal qui est relie au serveur fron- 
tal, et dans lequel le serveur dorsal est configure 
pour fournir le service cible. 

Precede tel que defini dans la revendication 1 , dans 
lequel la premiere methode d'authentification (303) 
est choisie dans un groupe de methodes d'authen- 
tification comprenant Passport, SSL, NTLM et Di- 
gest. 
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9. Procede tel que defini dans la revendication 1 , dans 
lequel la seconde methode d'authentification (206) 
comprend un protocole d'authentification Kerberos. 

10. Support lisible par ordinateur comportant des ins- 5 
tructions executables par ordinateur pour effectuer 
des taches consistant a: 

identifier un service cible (Serveur B-D) pour le- 
quel un acces est recherche pour le compte d'un io 
client (202) qui a ete authentifie a I'aide d'une 
premiere methode d'authentification (303); 
amener un serveur (210) relie de maniere ope- 
rationnelle au service cible et au client a requerir 
un pouvoir de delegation de service (308) a son 15 
nom d'un tiers de conflance (204) en vertu d'une 
seconde methode d'authentification en Identi- 
fiant le client et le premier protocole d'authenti- 
fication; et 

amener le serveur a requerir du tiers de confian- 20 
ce en vertu de la seconde methode d'authenti- 
fication, un nouveau pouvoir de delegation de 
service (308) a son nom pour le client, destine 
a etre utilise par fe serveur et le service cible, 
de la part du tiers de confiance en vertu de la 25 
seconde methode d'authentification, le serveur 
fournissant au tiers de confiance un pouvoir de 
delegation (306) qui authentifie I'acces du ser- 
veur au service cible dans.un cadre restreint par 
le client, des informations concernant le service 30 
cible, et le pouvoir de delegation de service a 
son nom. 

11. Support lisible par ordinateur tel que defini dans la 
revendication 10, dans lequel le tiers de confiance 35 
(204) en vertu de la seconde methode d'authentifi- 
cation comprend un centre de distribution de cles 
(KDC). 

12. Support lisible par ordinateur tel que defini dans la 
revendication 1 1 , dans lequel le nouveau pouvoir de 
delegation de service (308) comprend un pouvoir de 
delegation de service delivre au nom du client et non 
au nom du serveur. 

45 

13. Support lisible par ordinateur tel que defini dans la 
revendication 12, dans lequel le nouveau pouvoir de 
delegation de service est configure pour etre utilise 
par !e serveur (21 0) et le service cible (Serveur B-D). 

50 

14. Support lisible par ordinateur tel que defini dans la 
revendication 12, dans lequel le pouvoir de delega- 
tion (306) authentifiant le serveur (210) comprend 
un ticket de delivrance de ticket associe au serveur. 

55 

15. Support lisible par ordinateur tel que defini dans la 
revendication 10, comprenant egalement des ins- 
tructions pour: 



a la reception d'une demande requerant le nou- 
veau pouvoir de delegation de service (308) de 
la part du serveur (21 0), amener le tiers de con- 
fiance (204) en vertu de la seconde methode 
d'authentification a verifier que le client (202) a 
une delegation autorisee. 

16. Support lisible par ordinateur tel que defini dans la 
revendication 10, dans lequel le serveur (210) est 
un serveur frontal par rapport a un serveur dorsal 
qui est relie au serveur frontal, et dans lequel le ser- 
veur dorsal est configure pour fournir le service cible 
(Serveur B-D). 

17. Support lisible par ordinateur tel que defini dans la 
revendication 10, dans lequel la premiere methode 
d'authentification (303) est choisie dans un groupe 
de methodes d'authentification comprenant Pass- 
port, SSL, NTLM et Digest. 

18. Support lisible par ordinateur tel que defini dans la 
revendication 10, dans lequel la seconde methode 
d'authentification (206) comprend un protocole 
d'authentification Kerberos. 

19. Systeme serveur comprenant: 

un moyen configure pour identifier un service 
cible (Serveur B-D) pour lequel un acces est re- 
cherche pour le compte d'un client (202) qui a 
ete authentifie a i'aide d'une premiere methode 
d'authentification (303), 

un moyen configure pour requerir un pouvoir de 
delegation de service (308) a son nom d'un tiers 
de confiance (204) en vertu d'une seconde me- 
thode d'authentification en identifiant le client et 
la premiere methode d'authentification, et 
un moyen configure pour requerir ensuite un 
nouveau pouvoir de delegation de service a son 
nom pour le client, destine a etre utilise par le 
systeme serveur et le service cible, de la part 
du tiers de confiance en vertu de la seconde 
methode d'authentification, 
le systeme serveur comprenant egalement un 
moyen configure pour fournir au tiers de con- 
fiance en vertu de la seconde methode 
d'authentification un pouvoir de delegation (306) 
qui authentifie I'acces du serveur au service ci- 
ble dans un cadre restreint par le client, des in- 
formations concernant le service cible, et le pou- 
voir de delegation a son nom. 

20. Systeme tel que defini dans la revendication 19, 
comprenant egalement un moyen configure pour de- 
livrer le nouveau pouvoir de delegation de service 
(308) au nom du client (202) et non au nom du sys- 
teme serveur (210). 
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21. Systeme tel que defini dans la revendication 20, 
dans leque! le nouveau pouvoir de delegation de ser- 
vice (308) est configure pour etre utilise par le sys- 
teme serveur (210) et le service cible (Serveur BD). 

5 

22. Systeme tel que defini dans la revendication 20, 
dans lequel le pouvoir de delegation (306) authenti- 
fiant le systeme serveur (210) comprend un ticket 
de delivrance de ticket associe au serveur. 

10 

23. Systeme tel que defini dans la revendication 19, 
dans lequel le systeme serveur (210) est un serveur 
frontal par rapport a un serveur dorsal qui est relle 
au serveur frontal, et dans lequel le serveur dorsal 

est configure pour fournir le service cible (Serveur 15 
BD). 

24. Systeme tel que defini dans la revendication 19, 
dans lequel la premiere methode d'authentification 
(303) est Tune d'un groupe de methodes d'authen- 20 
tification comprenant Passport, SSL, NTLM et Di- 
gest. 

25. Systeme tel que defini dans la revendication 19, 
dans lequel la seconde methode d'authentification 25 
(206) comprend un moyen configure pour utiliser un 
protocole d'authentification Kerberos. 
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